Link issue:

• All Bug and issue related shielded action #733
• Making IBC transfers from Shielded Address. #694

Bug 1: Wrong chain id passing for shielded IBC transfer ( only IBC shielded )

• Currently in IBC transfer function get chain ID from account like image below
  
• The chain id in the account is always taken from the .env file. It will not be updated according to the chain ID extension. That's why the chain ID is wrong
• Solution: Chain id should be get from redux: const chain = useAppSelector((state) => state.chain.config). This is the correct chain ID same as chain id of extension

Bug 2: Private key is not passing into shielded action ( both IBC shielded and internal shielded transfer )

• At present, the private key is not being passed for shielded actions. The private key must be passed along with the transaction to serve as the payer for fees and to process the transaction. Failure to include the private key results in this bug.
• Solution: We propose adding a parameter called transparentAddress specifically for shielded transfers. This transparentAddress parameter would facilitate the generation of the private key required for signing and paying for transactions. By including this parameter, ensuring that the necessary private key is provided, thus enabling seamless signing and payment for transactions.

Bug 3: Public key is missing in txArgs when execute shielded transfer ( both ibc shielded and internal shielded transfer )

• Same as bug 2, the public key should be passed as an argument in the build_transfer function. This argument is crucial for determining the payer of the transaction fees.
• Solution: Because the account don't have public key, so will mapping in redux to add public key into shielded account

Bug 4: disposable_signing_key should be false when using shielded transfer ( only internal shielded transfer )

• The current flag disposableSigningKey is set based on isShieldedSource. From my understanding, this flag indicates whether the signing key is disposable, and the validator is responsible for paying the transaction fee. Therefore, it's advisable to enable this flag only for voting proposal transactions.
• Solution: Remove this flag in transfer transaction